To access the contents, click the chapter and section titles.
Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96
Chapter 3 What Is a Well-Tuned System?
This chapter examines the attributes of a system that is performing well. A well-tuned system is a general term; as you will see in the next chapter, what is a good performing system for one site may not be the most optimal system for others.
Each system has its own performance criteria. In some cases, a system is tuned well if a strict response time criteria is met. In other situations, a system is tuned well if the throughput is optimized. In other cases, the system may be optimally tuned for backup and recovery. It is up to you to determine your performance criteria.
This chapter looks at some general cases and criteria for a well-tuned system. Later chapters in the book focus on specific problems and solutions that may be standing in the way of achieving a well-tuned system. It is important to look at the system as a whole and try to determine how it is balanced. This chapter is split into different sections for client/server computing, terminal-based (also known as host-based) computing, and batch computing. The end of the chapter lists a few exceptions to the general rules presented in the first parts of the chapter.
Client/Server Computing
Throughout the book are references to the client or front-end machine. This book defines the client to be the computer that requests information and presents this data to the user. In the case of a PC running Personal Oracle for Windows, the client and the server are the same machine. Similarly, a UNIX computer connected to terminals is also considered both the client and the server. The terminal does not present data to the user; rather, the UNIX system presents the data that the terminal merely displays.
In this book, I refer to a client as a computerPC or otherwiseseparate from the database server. Host-based computers are systems that contain the RDBMS and present the data to terminals.
Heres an example of a client/server application performing a transaction. The work is split into the following steps:
- 1. Load and initialize the application. This step includes loading the application code into memory and displaying the application screen(s).
- 2. Connect to the database server. This step can be accomplished with SQL*Net, ODBC, and so on.
- 3. Accept data from the user. Data can be submitted from the keyboard, mouse, bar-code scanner, or some other means.
- 4. Process the data into the proper form to transmit to the server. This generally means forming the data into a structure that is passed to the database protocols along with any control information that must be added (such as the transaction type, amount of data being transmitted, and what stored procedures are to be executed).
- 5. Transmit the data to the server.
- 6. Wait for a response from the server.
- 7. Receive the data back from the server. In this step, some error checking is typically done to verify that the server has not sent back any error codes.
- 8. Format the data back into a form that the application code needs for its processing.
- 9. Bring up additional applications (optional). An application may invoke another application such as a spreadsheet or multimedia viewer.
- 10. Present the data to the user. This is done in whatever format the application requires (such as text, graphics, video, audio, and so on).
The following sections take each component involved in this process and examine what is optimal for it. The following sections look in turn at the client, the server, and the network used to connect the client and the server.
The Client or Front-End Machines
Typically, clients fall into one of several categories: those that perform purely presentation services, those that do some form of data manipulation, and those that may even have a local database for some static tables such as selection lists. If the client does data manipulation, the task may be as simple as sorting the data or as complex as joining the data from several different data sources.
For all three of these client models, it is important that the client has sufficient resources to perform its function. There should be no significant delays caused by presenting or manipulating the data. The performance the user sees is end-to-end performance. The time between when the last character is typed by the user and when the last bit of data is displayed is considered the response time (see Figure 3.1). The response time is the meter by which the user judges the performance of the system. In most cases, systems are tuned for this response time.
Figure 3.1 The user response time.
NOTE: In most cases, systems are tuned for response times. There are exceptionssuch as when response time must be sacrificed to load large amounts of data within a certain time interval.
If the goal is optimizing response time, the criteria for a good-performing client is to add minimal delays to response time. It doesnt benefit you to have the fastest server available if a 10-second response time is caused by a 1-second turnaround at the server and 9 seconds displaying the data. The user experiences long response times and is not satisfied.
As you see in Chapter 4, Tuning Methodology, when you benchmark a system, it is important to keep in mind response times as well as system throughput. Most benchmark tests today have very tight response-time criteria.
The Server
It is the job of the server to take requests from the clients, process the data as quickly and efficiently as possible, and pass the data back to the user. If the client machine typically serves only one user, response time is the highest criteria. For the server, even though response time is important, throughput is typically the most important factor.
Because the server processes information for hundreds or perhaps thousands of clients, the needs of all the users are more important than the needs of any one particular user. It is the job of the server to process as many transactions as quickly as possible. This goal is accomplished by balancing the system to respond as quickly as possible to each request and at the same time to make sure that each request gets an equal share of the systems processing power.
A well-performing server provides good response times for each users requests. In some cases, it may be desirable for some users to get a low priority (such as for a decision support task) while maintaining good throughput for OnLine Transaction Processing (OLTP) tasks, such as order entry and account inquiries.
|